This disclosure relates generally to the field of computer systems and software architectures. More specifically, the disclosure provided herein relates to quality of service (“QoS”) in service-oriented architectures.
Applications or software systems built upon a service-oriented architecture (‘SOA”) are generally structured as a collection of interacting and interoperable services in which functionality is exported through well-defined interfaces. Traditionally, SOAs are implemented by a single organization that owns and operates all services. In such architectures, there is typically only one instance of each service and the bindings of client applications to services (or services to services) are static. However, with the advent of cloud computing and software as a service (“SaaS”), a distributed SOA may be implemented in which the services are owned and operated by multiple service providers with multiple administrative domains, and that are potentially widely geographically distributed, even across continents.
Further, some services may have multiple implementations that are discovered using one or more discovery services. Such SOAs may have numerous users and applications utilizing the services, where the users' access patterns and frequency varies over time. Services may be provided on multiple levels, including application services implementing specific functionality, platform services providing an integrated environment in which to implement and deploy software services and applications, and infrastructure services for providing storage, processing, networking, and other hardware and technology resources upon which other services may execute. Examples of applications that may be implemented on distributed SOAs include business applications, such as enterprise resource planning (“ERP”) and customer relationship management (“CRM”), as well as consumer services, such as e-mail.
Distributed SOAs may provide many advantages over other application architectures, including service abstraction and dynamic configuration. Through service abstraction, the consumer of a service does not require any knowledge of how the service operates, which programming languages are used to implement the service, or on which operating system the service implementation executes. Instead, given the service interface, a user wanting to access the functionality implemented by the service just writes code to access the service through that interface and then handles the service output. Dynamic configuration allows for the binding of the consumer to a specific service instance, e.g. IP address, port, and access protocol, that actually provides the service, which can be dynamic and change from one execution to another. In addition, the structure of an application program in a distributed SOA may include programs that use one or more services in the architecture and those services may in turn utilize yet more services.
While the independent nature of the various services and features such as dynamic configuration provide some inherent advantages in the dependability of such SOAs, distributed SOAs also introduce many dependability and QoS challenges, including the difficulties associated with handling the partial failure of an executing program when a machine crashes, the need to deal with data consistency across machines in similar situations, the possibility of partitioned execution, and the like. An application executing on a distributed SOA may encounter faults in locating a service provider, including no service found, wrong service found, and timeout; faults in connecting with a service provider, including binding denied due to lack of authentication or authorization, binding to wrong service, and timeouts; as well as execution faults, such as service crash, incorrect results, and timeouts.
Because distributed SOAs often span multiple administrative domains, even within a single company, issues with trust between the different services may be introduced. In addition, software upgrades or other scheduled downtime in one administrative domain may interfere with applications spanning multiple domains, potentially resulting in unexpected application failures. Other QoS attributes such as timeliness and predictable application performance become challenging in a distributed SOA. Each service may execute on dedicated resources, but the workload of the service may depend on the cumulative workloads of all applications and other services that use this service. The workload of the service naturally dictates its response time. As a result, it may become increasingly difficult to predict the response time of an application since an unrelated application may suddenly start using, or increase its usage of, a shared service. The fact that new applications are introduced into the system may also increase the difficulty of predicting service workload.
Other QoS challenges result from the dependencies that can arise as a result of the invocation pattern within a SOA. As described above, in a distributed SOA, an application uses one or more services in the architecture, which in turn may use many other services. The services used may potentially be located all over the world, and be owned and operated by various organizations. As a result, the transitive closure of the services and organizations on which the application depends can become large and can in fact change over time due to dynamic binding. Similarly, the provider of a service will generally not know of all the applications and organizations that depend on its service. As a result, failures, maintenance actions, termination, or even updates of a service instance may have unanticipated consequences for multiple upstream and downstream services. Such extensive sets of dependencies also introduce security and trust challenges. Specifically, the information flow from one service to another is not visible to the application designer, who may know what is passed to or from a service, but not whether the service passes the information to other services potentially untrusted by the application designer.
Finally, the computing and networking infrastructure used may have an impact on QoS as well. For example, the emergence of cloud computing may introduce additional dependability challenges for SOAs when some of the services are executed on third-party cloud infrastructures. While cloud computing is often envisioned as a dynamic infrastructure that can automatically flex to accommodate changes in workloads and react to failures, it still introduces yet another entity that the end application will depend on both for uninterrupted operation and for assurance that data passed to and from the services remain private and uncorrupted.